Dual-mode bus station and system for communications

ABSTRACT

A bus station in the form of a hardware dongle, operates in conjunction with a USB Device running suitable software. When the bus station determines that a bus host is connected to a first bus communication port thereof, it acts as a transceiver to allow conventional bus communications between said bus host and a bus device connected to a second bus communication port thereof. When the bus station determines that a bus device running suitable software is connected to the first bus communication port thereof, it acts as an alternate host to allow bus communications between said bus device connected to the first bus communication port and a bus device connected to a second bus communication port.

This invention relates to a bus connection system, and in particular toa device which can be used with electronic equipment in a buscommunication system to allow the equipment to act as a host within thesystem.

The Universal Serial Bus (USB) communication system is becoming verywidespread.

In a USB system, it is possible to interconnect many items of electronicequipment, such as personal computers, scanners, mobile phones,printers, etc. In any system, one item of equipment is always designatedas the USB host, which controls connections with all of the other items,or USB devices. Personal computers are typically provided with thehardware and software required to allow them to act as USB hosts, butother items are typically not provided with the required hardware andsoftware, and thus can only act as USB devices.

There are however situations in which it would be useful for an item ofequipment to be able to act as a USB host, without requiring majormodification of the equipment.

According to an aspect of the present invention, there is provided a busstation, preferably in the form of a hardware dongle, which can beconnected to the bus communication port of a bus communication device,enabling it to act as a bus host. In the preferred embodiments of theinvention, the bus station operates in the USB system, although theinvention is also applicable to other bus communication systems.

More specifically, one aspect of the present invention provides a busstation which, when it determines that a bus host is connected to afirst bus communication port thereof, acts as a transceiver to allowconventional bus communications between said bus host and a bus deviceconnected to a second bus communication port thereof; and which, when itdetermines that a bus device running suitable software is connected tothe first bus communication port thereof, acts as an alternate host toallow bus communications between said bus device connected to the firstbus communication port and a bus device connected to a second buscommunication port.

FIG. 1 is a block schematic diagram of a bus communication system.

FIG. 2 is a block diagram showing the hardware and software in thesystem of FIG. 1.

FIG. 3 is a flow chart showing a method in accordance with an aspect ofthe present invention.

FIG. 1 is a block schematic diagram of a bus communication system inaccordance with the invention.

The system 2 comprises a first USB Device 4 with a USB port 6, a secondUSB Device 8 and a dongle 10.

In this illustrated embodiment, the first USB Device 4 is a personaldigital assistant (PDA), but it will be appreciated that the inventionis applicable to any USB Device such as a mobile communications device,digital camera or a personal organizer.

The second USB Device 8 may be any USB Device including a printer,mouse, hard disk or modem.

The dongle 10 comprises an Embedded USB Host/Device Controller 12 with afirst host port H1 and a second host port H2, and a low power MicroController Unit (MCU) 14.

The first host port H1 of the dongle 10 may be connected, as shown inFIG. 1, to the USB port 6 of the PDA 4. When the first host port H1 ofthe dongle 10 is connected to the USB port 6 of the PDA 4, the PDA iseffectively enabled to act as a USB Host, and: the second host port H2of the dongle 10 then effectively functions as a Host port of the PDA 4.Thus, the PDA 4 may control communications with any USB Device connectedto the second host port H2 of the dongle 10 by means of a USB bus 15.

It should be noted that, while the first host port H1 and the secondhost port H2 are shown here connected to the same USB Host/DeviceController 12, it would be possible for the MCU 14 to communicate withthe first host port H1 and the second host port H2 through twoindependent USB Host/Device Controllers, the first being dedicated tocommunication with the PDA 4, and the second being dedicated tocommunication with the connected USB device, or devices, 8.

In order to allow the PDA 4 to act as a USB Host when connected to thedongle 10, the PDA 4 requires a driver update.

The driver update is specific to the particular USB Device which is inuse, and serves to add in a Virtual Hardware Abstraction Layer(VirtualHAL) software driver, which runs on top of the existing USBDevice Hardware in the PDA 4.

FIG. 2 is a block diagram of the hardware and software in the system ofFIG. 1.

As is conventional, the USB Device 4 has an operating system 18, a HostStack 20 and Device Stack and Device Hardware 22. In order to be able toact as a USB Host, the PDA 4 also runs the VirtualHAL driver software16. When the USB Device 4 is running the VirtualHAL driver software 16,it is sometimes referred to herein as a HostOnDevice.

The dongle 10 comprises Host Hardware 12 (that is, the USB hostcontroller), MCU 14 and SoftHost Firmware 24.

The SoftHost protocol layer, which will be described in more detailbelow, controls the communications between the device 4 and the dongle10 over the dongle connector 28.

FIG. 3 is a flow diagram illustrating the operation of the dongle 10,under the control of the MCU 14. Upon powering up, at step 32 in FIG. 3,the MCU polls the first host port H1 in step 34, to determine whetherthere is any connection thereto. If there is no connection, the processends at step 36.

If there is a connection, the MCU determines in step 38 whether there isa USB Host connected to the first host port H1. If there is a USB Hostconnected to the first host port H1, then the process passes to step 40,in which the dongle 10 acts as a USB transceiver. That is, it passescommunications directly between the first host port H1 and the secondhost port H2, allowing the connected USB Host to control communicationswith any USB device (or devices) connected to the second host port H2 inthe conventional way.

If the MCU determines in step 38 that there is a USB Device, rather thana USB Host, connected to the first host port H1, the process passes tostep 41, in which it determines if there is a USB Host connected to thesecond host port H2. If so, then in step 42 the USB Device core withinthe USB Host/Device Controller 12 operates to allow conventional USBcommunications between the USB Device connected to the first host portH1 and the USB Host connected to the second host port H2.

If there is a USB Device connected to the second host port H2, the MCU14 enumerates the USB Device connected to the first host port H1 in step43, and checks if it is a device running VirtualHAL. If the MCUdetermines in step 43 that the connected device 4 is not runningVirtualHAL, it will disable the device 4 in step 44 and, for example,will trigger a flashing LED, signaling that the connected device 4 doesnot support VirtualHAL.

If the MCU determines in step 42 that the connected device 4 is runningVirtualHAL, (i.e. that it has a VirtualHAL driver 16) the MCU 14 will gointo operational mode in step 46, allowing the dongle 10 (together withthe device 4) to act as an alternate USB Host. In this mode, which willbe described in more detail below, the dongle 10 can controlcommunications with any USB device (or devices) connected to the secondhost port H2.

In a conventional system, where a personal computer is a USB Host, aHost Stack accesses underlying USB Hardware through the HostHAL.Similarly, in a conventional PDA USB Device, a Device Stack accessesunderlying USB hardware though a Device HAL.

However, in accordance with the invention, in the SoftHost system, whenthe Host Stack (or host station driver software) 20 needs to access theHost Hardware 12, it communicates the access operation details to theVirtualHAL Driver 16. The VirtualHAL Driver 16 wraps these accessoperation details in a pre-determined SoftHost Protocol. The SoftHostprotocol packet is sent out through the existing USB Device Hardware 22when the SoftHost Dongle 10 polls it for outstanding SoftHost Protocolpackets.

Thus, the VirtualHAL Driver software 16 emulates the presence of a hostcontroller towards the host station driver software. That is, from thepoint of view of the Host Stack 20, communicating with the VirtualHALDriver 16 is no different from communicating with a HostHAL in aconventional system. The Host Stack 20 will see an actual Host Hardwarethrough the VirtualHAL Driver 16.

Conversely, the VirtualHAL Driver software 16 emulates the presence of adevice controller towards the device controller (or device stack) 22.The VirtualHAL Driver software 16 thus translates communications betweenthe host station driver software 20 and the device controller.

The SoftHost Protocol provides the following access functions:

-   -   Reading a register in the dongle Host Hardware 12    -   Writing a register in the dongle Host Hardware 12    -   Reading buffer memory in the dongle Host-Hardware 12    -   Writing buffer memory in the dongle Host Hardware 12

More advanced functions could be added to improve the systemperformance, for example, a function that reads a register, AND/ORs itwith a value and writes the amended value back into the register.

The SoftHost Protocol defines the method by which the Host Stack 20running on VirtualHAL may access the hardware of the Host Controller 12using the Device Controller hardware. The SoftHost protocol is describedin detail below. In this description, the term “HostDongle” is used torefer to the dongle 10, while the term “HostOnDevice” is used to referto the device 4, namely an embedded system with USB device hardware 22,running a Host Stack 20 on Virtual 16.

The SoftHost protocol starts at the end of FIG. 3, at the point wherethe HostDongle 10 has enumerated the connected device 4 and theconnected device 4 is confirmed to be a HostOnDevice.

In operational mode, the MCU 14 sets up an interrupt pipe and polls theVirtualHAL driver 16 for data every millisecond. Data sent between thedevice 4 and dongle 10 is sent by means of the SoftHost protocol, in theform of SoftHost Packets. If the Host Stack 20 on the PDA 4 has sent ahardware access request through the VirtualHAL Driver 16, the VirtualHALDriver 16 will send the request as a SoftHostPacket when the first hostport H1 of the dongle 10 polls it through the interrupt pipe.

The MCU 14 will retrieve this SoftHost Packet from the buffer memory ofthe embedded USB Host Controller 12 and execute the hardware accessaccordingly. If there is any data to be returned (read operations), theMCU 14 will send out the corresponding data through Host 1.

Traffic

The HostDongle 10 and the HostOnDevice 4 communicate using a dedicatedbidirectional bulk pipe. There are four types of payloads.

HRU (HostDongle Request Unit)

Sent by HostDongle 10

A bulk packet of 8 bytes payload

Used for polling the HostOnDevice 4

May contain Interrupt Information (HRU_IRQ)

HostDongle 10 ALWAYS sends a bulk-in of 64 bytes after sending the HRU.

HostOnDevice 4 would reply with NOB or CRP through this bulk-in.

NOB (No Outstanding Business)

Sent by HostOnDevice 4

A bulk packet of 8 bytes payload

Sent when there are no outstanding transactions

CRP (Common Request Packet)

Sent by HostOnDevice 4

A bulk packet of 16-64 bytes

Contains the results of previously received CRP commands, and an optimaldata set.

APR (As Per Requested)

Sent by HostDongle 10

A bulk packet of 16-64 bytes

The Flow

As in all USB systems, transfers start with an action by the Host. Inthe case of the SoftHost protocol, the SoftHost Dongle 10 is always theHost. All SoftHost transfer cycles starts with a HRU, as defined above.The current transfer cycle must be completed before the HostDongle 10starts the next transfer cycle.

Poll-Nothing Cycle: HRU-NOB

HostDongle 10 polls the HostOnDevice 4 for outstanding command sets. If

there are no outstanding command sets, HostOnDevice 4 replies with NOB.

Transactions:

HostDongle 10 sends BULK-OUT

HostDongle 10 sends DATA (HRU)

HostOnDevice 4 sends ACK

HostDongle 10 sends BULK-IN

HostOnDevice 4 sends DATA (NOB)

HostDongle 10 sends ACK

Poll-Something Cycle: HRU-CRP-APR

HostDongle 10 polls the HostOnDevice 4 for outstanding command sets.

HostOnDevice 4 sends outstanding command set by CRP. HostDongle 10executes the command and returns the results by APR.

Transactions:

HostDongle 10 sends BULK-OUT

HostDongle 10 sends DATA (HRU)

HostOnDevice 4 sends ACK

HostDongle 10 sends BULK-IN

HostOnDevice 4 sends DATA (CRP)

HostDongle 10 sends ACK

HostDongle 10 sends BULK-OUT

HostDongle 10 sends DATA (APR)

HostOnDevice 4 sends ACK

Interrupt Cycle: HRU_IRQ-CRP-APR

HostDongle 10 alerts the HostOnDevice 4 on outstanding hardwareinterrupts. HostOnDevice 4 decides on the appropriate command sets andsends them by CRP. HostDongle 10 executes the commands and returns theresults by APK HostOnDevice 4 MUST clear the outstanding interrupt ordisable the generation of HRU_IRQ, or the HostDongle 10 would sendHRU_IRQ continuously.

Transactions:

HostDongle 10 sends BULK-OUT

HostDongle 10 sends DATA (HRU_IRQ)

HostOnDevice 4 sends ACK

HostDongle 10 sends BULK-IN

HostOnDevice 4 sends DATA (CRP)

HostDongle 10 sends ACK

HostDongle 10 sends BULK-OUT

HostDongle 10 sends DATA (APR)

HostOnDevice 4 sends ACK

Packet Formats

HRU Format

-   -   The HRU contains the following information:        -   Current Frame Number    -   HcInterruptStatus of Host Controller 12 in HostDongle 10        -   Interrupt Status of Device Controller 22            NOB Format

No special information required

CRP and APR Format

Active bit in Header is 1 n for CRP, and 0 for APR.

CRP can be of a size of 16-64 bytes. The total size is made up of

-   -   A number of command sets (8 bytes each)    -   An optional data set.

Maximum number of command sets in a CRP is 8.

Maximum size of data set is 64-(8* number of command sets).

The multiple command sets in a single command request packet allows asequence of hardware accesses to be communicated in a single packet andthus reduces the latency transfer.

Command Set Format

Command Set is an 8-byte data structure. It contains the followinginformation:

Command Set Header (1 byte)

Command Set Index (2 bytes)

Command Set Data (4 bytes)

Command Set Aux (1 byte)

Bit 7 6 5 4 3 2 1 0 Group Active Remaining Sets OpCode Attribute Boolean0-7.0 means last set 0-15

OpCode Operation by MCU 0 Write [Aux] bytes from [Data] into [Index]register 1 Read [Aux] bytes from [Index] register into [Data] 2 Write[Data] bytes from DataSet into address location [Index] 3 Read [Data]bytes into DataSet from address location [Index] 4 Read [Aux] bytes from[Index] register, OR with [Data] and write back into [Index] register 5Read [Aux] bytes from [Index] register, AND with [Data] and write backinto [Index] register 6 Set polling rate to [Index] 7 Set HRU_IRQ On/Off8-15 Reserved. No Action by MCU

The Virtual Hardware Abstraction Layer (VirtualHAL) therefore providescomplete access to the target hardware on the connected dongle, usingthe USB Device hardware. In other words, the existing USB Devicehardware is used as an asynchronous microprocessor interface bus toallow the USB Host Driver to access the target hardware.

The use of VirtualHAL provides the advantages that the hardware dongledoes not need to handle USB software, which allows the dongle to be lowcost, and the Host software can be handled by the embedded system on theUSB Device.

Therefore, in the preferred embodiments of the invention, there isprovided a hardware dongle that allows a USB Device to attain thecapability of USB Host without changes to the existing hardware. Inorder to achieve this, the USB Device runs emulation software that canbe handled by the embedded system on the USB Device. This provides theadvantages that the hardware dongle does not need to handle USBsoftware, which allows the dongle to be low cost.

The invention has been described up to this point with reference to asystem in which the VirtualHAL driver software allows the USB Device tofunction as a USB Host in conjunction with the dongle 10. However,similarly structured Virtual driver software could be used to add inmultiple interface/functions to a system with USB Device capability. Forexample, the driver software could allows the USB Device to communicateover Bluetooth, IrDA, USB-OTG, or other communications protocols.

1. A bus station for use in a bus communication system comprising: afirst communication port and a second communication port, said busstation being arranged to operate in a first mode upon detection of thepresence of a host station coupled to said second port, said first modeof operation to pass communication between said host station coupled tosaid second port and a first device station coupled to said first port,said bus station further being arranged to operate as an alternate hoststation in a second mode of operation upon detection of the absence ofthe host station coupled to said second port, said bus station arrangedin said second mode of operation to communicate with said first devicestation coupled to said first port on behalf of a further device stationcoupled to said second port, said communication according to acommunication protocol wherein said bus station initiates communicationsand the further device station appears as a host station to the firstdevice station and performs operations, including communications,therewith.
 2. A bus station according to claim 1 wherein said busstation is arranged to operate as a USB transceiver in said first modeof operation and to operate as a USB host in said second mode ofoperation.
 3. A bus station according to claim 1 wherein said busstation further comprises transceiver circuitry coupled to said firstand second port for passing communication between said host stationcoupled to said second port and said first device station in said firstmode of operation.
 4. A bus station according to claim 1, wherein thebus station is further arranged to operate in the first mode upondetecting a host station coupled to the first communication port and topass communications between the host station coupled to the firstcommunication port and a device station coupled to the secondcommunication port in the first mode of operation.
 5. A bus stationaccording to claim 1, wherein the further device station coupled to thesecond communication port includes a device controller and the furtherdevice station is arranged to operate under control of host emulationsoftware.
 6. A bust station according to claim 5, wherein, in the secondmode of operation, the host emulation software emulates the presence ofhost station driver software to the first device station and the hostemulation software emulates the presence of device station driversoftware to the device controller of the further device station.
 7. Abus station according to claim 5, wherein, in the second mode ofoperation, the host emulation software translates communication betweenthe device controller of the further device station and the first devicestation coupled to the first communication port.
 8. A bus station foruse in a bus system, comprising: a device controller coupled to acommunication port, the bus station being arranged to operate as adevice station, said bus station further being arranged to operate undercontrol of system software including an operating system and hoststation driver software, the host driver software being arranged tocommunicate with a host controller and to pass information to and fromthe operating system, said system software further including hostemulation software being arranged to emulate the presence of a hostcontroller towards the host station driver software and the presence ofdevice station driver software towards the device controller, furtherbeing arranged to translate communication from the host station driversoftware to the device controller and vice versa.
 9. The system of claim8, wherein the communication port is a USB communication port.
 10. A buscommunication system comprising: a first bus station having a devicecommunication port, and a second bus station having a firstcommunication port and a second communication port, said second busstation being arranged to operate in a first mode upon detection of thepresence of a host station coupled to said second port and to operate ina second mode upon detection of the absence of a host station coupled tosaid second port; wherein said first station comprises a devicecontroller coupled to said device communication port and being arrangedto operate under control of system software, having an operating systemand host station driver software being arranged to communicate with ahost controller and to pass information to and from the operatingsystem, wherein said system software further comprises host emulationsoftware being arranged to emulate the presence of a host controllertowards the host station driver software and the presence of a hostcontroller towards the device controller, further being arranged totranslate communications from the host station driver software to thedevice controller and vice versa.
 11. The system of claim 10, whereinthe device communication port, the first communication port, and thesecond communication port are USB communication ports.
 12. A bus systemaccording to claim 10, wherein the second bus station further includestransceiver circuitry coupled to said first and second communicationports for passing communications between said host station coupled tosaid second port and said first bus station in said first mode ofoperation.